1. Вошли в систему под своей учетной записью. Убедились, что SELinux работает в режиме enforcing политики targeted с помощью команд getenforce и sestatus (рис. [-@fig:001]).

2. Запускаем сервер apache, далее обращаемся с помощью браузера к веб-серверу, запущенному на компьютере, он работает, что видно из вывода команды service httpd status (рис. [-@fig:002]).

3. С помощью команды ps auxZ | grep httpd найдем веб-сервер Apache в списке процессов. Его контекст безопасности - httpd_t (рис. [-@fig:003]).

4. Просмотрим текущее состояние переключателей SELinux для Apache с помощью команды sestatus -bigrep httpd (рис. [-@fig:004]).

5. Просмотрим статистику по политике с помощью команды seinfo. Множество пользователей - 8, ролей - 39, типов - 5135. (рис. [-@fig:005]).

6. Типы поддиректорий, находящихся в директории /var/www, с помощью команды ls -lZ /var/www следующие: владелец - root, права на изменения только у владельца. Файлов в директории нет (рис. [-@fig:006]).

7. В директории /var/www/html нет файлов. (рис. [-@fig:007]).

8. Создать файл может только суперпользователь, поэтому от его имени создаем файл touch.html cо следующим содержанием (рис. [-@fig:008]).

9. Проверяем контекст созданного файла. По умолчанию это httpd_sys_content_t (рис. [-@fig:009]).

10. Обращемся к файлу через веб-сервер, введя в браузере адрес http://127.0.0.1/test.html. Файл был успешно отображён (рис. [-@fig:010]).

11. Изучим справку man httpd_selinux. Рассмотрим полученный контекст детально. Так как по умолчанию пользователи CentOS являются свободными от типа (unconfined в переводе с англ. означает свободный), созданному нами файлу test.html был сопоставлен SELinux, пользователь unconfined_u. Это первая часть контекста.

Продолжение пункта 11

Далее политика ролевого разделения доступа RBAC используется процессами, но не файлами, поэтому роли не имеют никакого значения для файлов. Роль object_r используется по умолчанию для файлов на «постоянных» носителях и на сетевых файловых системах. (В директории /ргос файлы, относящиеся к процессам, могут иметь роль system_r. Если активна политика MLS, то могут использоваться и другие роли, например, secadm_r. Данный случай мы рассматривать не будем, как и предназначение :s0). Тип httpd_sys_content_t позволяет процессу httpd получить доступ к файлу. Благодаря наличию последнего типа мы получили доступ к файлу при обращении к нему через браузер. (рис. [-@fig:011]).

Продолжение пункта 11

12. Изменяем контекст файла /var/www/html/test.html с httpd_sys_content_t на любой другой, к которому процесс httpd не должен иметь доступа, например, на samba_share_t: chcon -t samba_share_t /var/www/html/test.html ls -Z /var/www/html/test.html Контекст действительно поменялся (рис. [-@fig:012]).

13. При попытке отображения файла в браузере получаем сообщение об ошибке (рис. [-@fig:013]).

файл не был отображён, хотя права доступа позволяют читать этот файл любому пользователю, потому что установлен контекст, к которому процесс httpd не должен иметь доступа.

14. Просматриваем log-файлы веб-сервера Apache и системный лог-файл: tail /var/log/messages. Если в системе окажутся запущенными процессы setroubleshootd и audtd, то вы также сможете увидеть ошибки, аналогичные указанным выше, в файле /var/log/audit/audit.log. (рис. [-@fig:014]).

15. Чтобы запустить веб-сервер Apache на прослушивание ТСР-порта 81 (а не 80, как рекомендует IANA и прописано в /etc/services) открываем файл /etc/httpd/httpd.conf для изменения. (рис. [-@fig:015]).

16. Находим строчку Listen 80 и заменяем её на Listen 81. (рис. [-@fig:016]).

17. Выполняем перезапуск веб-сервера Apache. Произошёл сбой, потому что порт 80 для локальной сети, а 81 нет (рис. [-@fig:017]).

18. Проанализируем лог-файлы: tail -nl /var/log/messages (рис. [-@fig:018]).

19. Просмотрим файлы /var/log/http/error_log, /var/log/http/access_log и /var/log/audit/audit.log и выясним, в каких файлах появились записи. Запись появилась в файлу error_log (рис. [-@fig:019]).

20. Выполняем команду semanage port -a -t http_port_t -р tcp 81 После этого проверяем список портов командой semanage port -l | grep http_port_t Порт 81 появился в списке (рис. [-@fig:020]).

21. Перезапускаем сервер Apache (рис. [-@fig:021]).

22. Теперь он работает, ведь мы внесли порт 81 в список портов httpd_port_t (рис. [-@fig:022]).

23. Возвращаем в файл /etc/httpd/httpd.conf порт 80, вместо 81. Проверяем, что порт 81 удален, это правда. (рис. [-@fig:023]).

24. Далее удаляем файл test.html, проверяем, что он удален(рис. [-@fig:024]).

Выводы

В ходе выполнения данной лабораторной работы были развиты навыки администрирования ОС Linux, получено первое практическое знакомство с технологией SELinux и проверена работа SELinux на практике совместно с веб-сервером Apache.